When an attempt is made to execute a trick play operation that changes the reproducing speed and/or direction of video streams compressed by MPEG-2 or the like (referred to below as normal play streams to distinguish them from trick play streams), the structure generally adopted in the past, especially in video reproducing systems using networks, has been one that extracts only the temporally intermittent intra-frame coded pictures (I-frames, which occur at intermittent intervals) from the normal play stream and delivers the extracted I-frames continuously to the terminal, where they are reproduced after being received.
With the conventional method above, however, since only the I-frames are extracted from the normal play stream, the result is sometimes a stream that departs from the usual MPEG-2 structure. A consequent problem has been that to enable reproduction of a trick play stream consisting only of I-frames, some sort of contrivance has had to be provided in the decoder at the receiving end.
Since only the I-frames, which have a large code size, are extracted and delivered continuously, the amount of code transferred per unit time (the transfer rate) is extremely large; this has led to problems such as the overflow of buffers on the transfer path (multiplexer and demultiplexer buffers, for example), the exceeding of network bandwidth limits, and the overflow of decoder buffers at the receiving end. To enable the transfer of trick play streams with increased transfer rates, it has therefore been necessary to expand network bandwidth and increase the memory size of buffers on the transfer path.
The network bandwidth problem is especially serious; although it depends on the code size of the I-frames, trick play methods that use only I-frames generally need about three times as much bandwidth as needed for normal play. Practically speaking, however, it would be difficult to increase bandwidth just to accommodate trick play. One method of dealing with this problem is to provide a separate trick play stream, but although this is simple in terms of system configuration, it is problematic because, since a trick play stream has to be prepared separately in addition to the normal play stream, the amount of stored data increases and the normal play stream and the trick play stream have to be managed on a related basis.
A method of addressing these problems by distributing data with repeat pictures, coded as macroblocks having zero motion vectors and zero prediction error, inserted following the intra-frame or intra-field coded data in a trick play stream has been proposed (see, for example, Patent Document 1). When trick play is executed by this method of inserting repeat pictures, the transfer rate is greatly reduced, because I-frames of large code size are followed by repeat pictures of very small code size; an increase in the transfer rate is thereby prevented, and it is not necessary to provide a large memory for trick play. The reproduced trick play stream moreover has the same syntactic structure as a normal play stream, so there is no need to add separate logic and circuitry to process trick streams, or to switch over to special logic during trick play.
A method of generating data during a trick play session between a server and a terminal over a network has been proposed in which, when trick play is performed, a trick play stream is assembled from I-frames extracted from the normal play stream and from stored repeat picture data, and stuffing is inserted following the repeat pictures according to the VBV delay (the residence time of data in the decoder buffer) of the extracted I-frame data so as not to produce a failure of the VBV buffer (Video Buffering Verifier buffer: a virtual buffer for controlling the amount of code generated) (see, for example, Patent Document 2).
Patent Document 1: Japanese Patent No. 3304634 (p. 10, FIG. 1)
Patent Document 2: Japanese Patent Application Publication No. 2002-77811 (p. 12, FIG. 1)